home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19971216-19980424 / 000240_news@newsmaster….columbia.edu _Tue Feb 17 14:53:12 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA01179
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 17 Feb 1998 14:53:12 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA25865
  7.     for kermit.misc@watsun; Tue, 17 Feb 1998 14:53:11 -0500 (EST)
  8. Path: news.columbia.edu!panix!nntprelay.mathworks.com!newsfeed.direct.ca!newshub1.home.com!news.home.com!news.rdc1.sfba.home.net!cypher.cagent.com!user
  9. From: tsw@cagent.com (Tom Watson)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: k95 Setting Parity Bit?
  12. Date: Tue, 17 Feb 1998 11:13:04 -0800
  13. Organization: CagEnt, Inc.
  14. Lines: 65
  15. Message-ID: <tsw-1702981113040001@cypher.cagent.com>
  16. References: <6c8b9l$84r$1@goanna.cs.rmit.edu.au> <6c9p95$cup$1@apakabar.cc.columbia.edu>
  17. NNTP-Posting-Host: alfred.cagent.com
  18. Cache-Post-Path: alfred.cagent.com!unknown@cypher.cagent.com
  19. Xref: news.columbia.edu comp.protocols.kermit.misc:8430
  20.  
  21. In article <6c9p95$cup$1@apakabar.cc.columbia.edu>,
  22. fdc@watsun.cc.columbia.edu (Frank da Cruz) wrote:
  23.  
  24. <<<deletia regarding how to set stop bits>>>
  25.  
  26. > There is presently no way to set stop bits in K95.  To our knowledge, the
  27. > last device to need any number of stop bits other than 1 was the Teletype
  28. > machine, circa 1929, to give its big clunky print head time to turn around
  29. > to home position between characters (these were still in use through about
  30. > the mid 1970s, and I'm sure some are still in service today, but I don't
  31. > think you'd be using K95 to communicate with one) (*).
  32. > 
  33. <<<deletia>>>
  34. > 
  35. > (*) Some Telecommunications Devices for the Deaf (TDDs) might still use
  36. >     Teletypes, but K95 could not communicate with them anyway, since they
  37. >     use 5-bit Baudot code rather than ASCII.  Most modern TDDs use ASCII.
  38.  
  39. Some history on stop bits:
  40.  
  41. True that 5-level (Baudot) teletypes used a different stop bit length. 
  42. Typically it was 1.5 times the normal bit size.  This was for ONLY 5 level
  43. machines.  On the other hand, the "modern" teletype Model 33 and Model 35,
  44. which both ran at 110 bps used TWO stop bits.  These were very popular
  45. until at least the mid to late 70's.
  46.  
  47. General rules (there are probably exceptions):
  48. 5 level machines 1.5 stop bits (baudot code)
  49. 110 bps machines, ASCII coded (TTY 33, TTY 35) 2 stop bits.
  50. All other machines - 1 stop bit.
  51.  
  52. Actually the "stop bit" can be longer than the above, as it is the 'idle'
  53. state of the line.  The above are the minimum allowed.
  54.  
  55. Early UART chips allowed for different character lengths.  These were 5,
  56. 6, 7, and 8 bits per character (data).  Another pin was the "1, or other
  57. than 1" stop bit(s).  For 5 bits per character, this was set at 1.5 bits,
  58. otherwise, 2 stop bits.  Parity was "in addition to" the number of data
  59. bits.
  60.  
  61. This gives us the current scheme of 7E1, and 8N1, both having 8 bits
  62. between the start and stop bits.
  63.  
  64. Other schemes were 6 bit characters with parity (total of 7 bits) used for
  65. IBM 2741 terminals.  These beasts had all sorts of wierd protocols to turn
  66. around the line, as they were half duplex.  Since they ran at 15
  67. characters/sec, the bit rate was 134.5 bps to get the timing "just
  68. right".  These relics still have a legacy in the fact that the bit rate of
  69. 134.5 can usually be set on many UARTs today.
  70.  
  71. The only thing that having TWO stop bits adds is a little bit of delay
  72. between characters.  But that will lead to problems.  In one case, I had a
  73. machine that (by default) used two stop bits, but was sent data with one
  74. stop bit.  On the reception end, this doesn't matter (two stop bits only
  75. is relevant to sending).  The problem arose when the remote machine (with
  76. two stop bits) was echoing characters.  It had only a one character
  77. buffer, and soon (about 1/2 way thru a line of text), it couldn't keep
  78. up.  This caused a lost character in the receive stream.  Turning off the
  79. echo, or changing to one stop bit cured the problem.
  80.  
  81. Moral:  one stop bit is enough.
  82.  
  83. -- 
  84. tsw@cagent.com         (Home: tsw@johana.com)
  85. Please forward spam to: annagram@hr.house.gov (my Congressman), I do.